The Domain Name System (DNS) is the part of the Internet infrastructure that translates human-readable domain names into the Internet Protocol (IP) numbers needed to establish TCP/IP communications over the Internet. That is, DNS allows users to refer to web sites, and other resources, using memorable domain names, such as “www.en.example.com,” rather than the numeric IP addresses, such as “123.4.56.78,” which are machine readable addresses used by software to communicate with computers on the Internet. Each domain name is made up of a series of character strings (labels) separated by dots. The right-most label in a domain name is known as the “top-level domain” (TLD). Examples of well-known TLDs are “.com,” “.net,” “.org.” etc. Each TLD supports second-level domains, listed immediately to the left of the TLD, e.g., “example” in “www.example.com.” Each second-level domain can support a number of third-level domains located immediately to the left of the second-level domain, e.g., “en” in “www.en.example.com.” There can be additional level domains as well. For example, a domain with additional domain levels could be “www.landscape.photos.example.com.”
It should be noted that a single IP address, e.g., one assigned to a single server, can support numerous domain names. That is, different domain names may resolve to the same server, and that server can then determine what content to provide based on the requested domain name and/or additional non-domain information. This is sometimes referred to as virtual hosting.
Additional non-domain information may be included in a Uniform Resource Identifier (“URI”) structure that includes the domain name. For example, a “path” part of a URI is a sequence of segments separated by a forward slash (“/”). This non-domain information may be included immediately to the right of the domain name, such as the “blog” in “www.example.com/blog/today.htm,” and may be used by a server or other receiving device to identify and deliver specific content or run particular code. Other examples of non-domain information may include queries and fragments, the specifics of which are understood by those of ordinary skill in the art and are not discussed in detail herein. Combinations of this information may be included in web page hyperlinks that navigate a user to another section of the same page or to another web page. Thus, as can be seen in the various examples provided above, and as appreciated by those of skill in the art, a domain, such as the second level domain “example.com,” may contain a variety of different Internet accessible information with different addresses and other means of identification.
The actual registration of domain names is performed by companies referred to as domain name registrars (“registrars”). Registrars register domain names with registries. For example, an end user submits to a registrar a domain name for registration and provides an IP address to which the domain name should resolve. The registrar communicates with the registry to create a registry database record that can be used by the DNS to resolve the domain name to the IP address provided by the end user and that indicates the identity of the registrar through which the domain name was registered. With the exception of automatic, time-based expiration of the domain name registration at the registry, typically only the registrar designated in the domain name record at the registry can modify or delete registry database information about a domain name. An end user can switch registrars for their domain name(s) by following certain domain transfer procedures. Registrars may also act as a hosting provider, or the end user may have the domain hosted by a separate third-party domain hosting service.
A zone file is a text file that describes a portion of the DNS called a DNS zone. A zone file is organized in the form of resource records (RR) and contains information that defines mappings between domain names and IP addresses and other resources. The format of zone files is defined by a standard, with each line typically defining a single resource record. A line begins with a domain name, but if left blank, defaults to the previously defined domain name. Following the domain name is the time to live (TTL), the class (which is almost always “IN” for “internet” and rarely included), the type of DNS resource record (A, MX, SOA, etc.), followed by type-specific data such as the IPv4 address for A records. Comments can be included by using a semi-colon and lines can be continued by using parentheses. There are also file directives that are marked with a keyword starting with a dollar sign.
The DNS distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains, and in turn can assign other authoritative name servers for their sub-domains. This mechanism generally helps avoid the need for a single central register to be continually consulted and updated. The DNS resolution process allows for users to be directed to a desired domain by a reverse lookup process whereby the user enters the desired domain, and the DNS returns appropriate IP numbers. During the DNS resolution process, a request for a given domain name is routed from a resolver (e.g. a stub resolver) to an appropriate server (e.g. a recursive resolver) to retrieve the IP address. To improve efficiency, reduce DNS traffic across the Internet, and increase performance in end-user applications, the DNS supports DNS cache servers that store DNS query results for a period of time determined by the time-to-live (TTL) of the domain name record in question. Typically, such caching DNS servers, also called DNS caches, also implement the recursive algorithm necessary to resolve a given name starting with the DNS root through to the authoritative name servers of the queried domain. Internet service providers (ISPs) typically provide recursive and caching DNS servers for their customers. In addition, home networking routers may implement DNS caches and proxies to improve efficiency in the local network.
Although the distributed nature of the DNS provides significant advantages in terms of the efficiency of the overall system, it also makes the system vulnerable to certain types of malfunctions and/or attacks at various nodes in the system. One particular problem that can occur is referred to as DNS cache poisoning. DNS cache poisoning occurs when data are introduced into a DNS name server's cache database that did not originate from authoritative DNS sources. This may result from deliberate attacks on a name server, or it may be an unintended result of, for example, a misconfigured DNS cache, or improper software design of a DNS applications. Thus, DNS cache poisoning can result in (1) resolution requests failing, such as when inaccurate or misconfigured IP address information is provided, or (2) a requesting user's resolution request being directed to a malicious site that spoofs the genuine domain and is used to illicitly obtain information such as account passwords, or to distribute malicious content, such as computer worms or viruses, that are delivered to the requesting user.
The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the DNS as used on IP networks. DNSSEC provides for the cryptographically signing of DNS-ready zone files, ensuring origin authentication and data integrity for DNS data, as well as authenticated denial of existence. In general, answers provided within DNSSEC are digitally signed, and, by checking the digital signature, a DNS resolver is able to check if the information corresponds to the information on the authoritative DNS server. DNSSEC uses public-key cryptography for the digital signatures and authentication. The DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root zone, which is a trusted third party.
To implement DNSSEC, several new DNS record types were created or adapted to use with DNSSEC, including RRSIG, DNSKEY, DS, NSEC, NSEC3, and NSEC3PARAM. For example, when DNSSEC is used, each authoritative answer to a DNS lookup will contain an RRSIG DNS record in addition to the record type that was requested. The RRSIG record is a digital signature of the answer DNS resource record set. The digital signature can be verified by locating the correct public key found in a DNSKEY record. The DS record is used in the authentication of DNSKEYs in the lookup procedure using the chain of trust. NSEC and NSEC3 records are used to provide the authenticated denial of existence responses for DNS records that do not exist.
The requirements of DNSSEC involve the use of different keys, stored both in DNSKEY records and from other sources to form trust anchors. There are, for example, Key Signing Keys (KSKs), which are used to sign other DNSKEY records, and Zone Signing Keys (ZSKs), which are used to sign other records. Because the ZSKs are under the control and use of a specific DNS zone, they can be switched more easily and more often. As a result, ZSKs can generally be much shorter (in terms of byte length) than KSKs, while still offering an acceptable level of protection.
Although protocols have been developed for the employment of DNSSEC, including the use of KSKs and ZSKs, there are numerous aspects of operating DNSSEC enabled domains, at the registrar and registry levels, that have not been addressed and/or optimized for large-scale use. For example, the entities (e.g., devices) that interact with the DNSSEC-enable DNS must obtain credentials (e.g., keys) required to decrypt RRSIG DNS records. However, an entity may lack such credentials or the credentials it possesses may be outdated. Accordingly, there is a need for a secure and reliable method for entities to obtain authentic credentials.